The proliferation of digital imaging devices has created color reproduction problems. Because each device interprets digital color values differently, the color appearance of a given digital color specification (in RGB, CMYK, or some other color space) varies from device to device. With the advent of color management systems, such as the Kodak Color Management System available from Eastman Kodak Co., this problem has been addressed by storing information about device color reproduction in “device color profiles” and defining a device-independent “profile connection space” (PCS) with characteristics based on the properties of human color vision.
When a user wants to take a digital image from some source device (such as an RGB scanner) and print it on some destination device (such as a CMYK printer), the color management system (CMS) software converts the RGB source image into a CMYK destination image in a way that substantially preserves the color appearance of the image. This procedure relies on the availability of a device color profile (DCP) for both the source and destination digital color imaging peripheral. The DCPs are stored on the user's computer system in a file format understood by the CMS. A common file format for DCPs is that promoted by the International Color Consortium (ICC). An ICC profile for a given imaging device must contain a transform that converts device coordinates (such as RGB or CMYK) to device-independent PCS values. This transform will be referred to using the notation [device>PCS] and which can be called a forward transform for convenience. For output devices (such as printers) the ICC profile also must contain a transform that converts PCS values to device coordinates, that is, [PCS>device] and which can be called a backward or reverse transform.
Current color management systems convert from source device coordinates to destination device coordinates by using the [device>PCS] transform from the source device profile and the [PCS>device] transform from the destination device profile, that is, [device>PCS]□[PCS>device]. To decrease the amount of time required to process an image from the source space to the destination space, a CMS typically composes or combines the two transforms into a single transform that converts directly from the source device space to the destination device space ([device A>device B]). A method for composition is disclosed in U.S. Pat. No. 5,432,906, incorporated by reference herein. This method roughly halves the amount of time it takes to process an image from a source to a destination space.
While the above cited method is very efficient, it does have some potential drawbacks. First, because the PCS must accommodate any device that will be used, the PCS encoding encompasses a larger domain or gamut of colors than any real device, as a result, the [PCS>device] destination transform must compress colors that are outside the color gamut of the given source device. This “gamut compression” problem is difficult and there is no one solution that is ideal for all images or all users. ICC profiles attempt to address this problem by providing four different [PCS>device] transforms or “rendering intents” each with a different gamut compression. However, this still does not always give the user sufficient flexibility in choosing a suitable gamut compression. Furthermore, the “gamut compression” problem is really a “gamut mapping” problem from the source gamut to the destination gamut. Since the destination profile is typically computed without foreknowledge of the source device, the gamut compression technique is typically a generic one that will give typically acceptable results for a range of devices but which is not optimized for any single device.
Another problem with current techniques is that they go through an intermediary color space, the PCS. This offers the advantage of decoupling the source and destination profiles. It essentially reduces the number of profiles required for M source devices and N destination devices from M*N to M+N.
However, it can also create problems. Although the transformation from source device space to PCS may retain the color appearance information from the source device, it may lose other desirable information. Sometimes, it is desirable to preserve other aspects of the source device color encoding. One example is the desire that colors at the corners of the source device encoding (such as a pure red with no green or blue [255,0,0]) preserve this relationship in the destination device encoding. Another example is the desire to retain similar black ink usage when converting from one CMYK space to another (known as CMYK re-targeting). This device-specific information is typically discarded by the [device>PCS] transform.
One general approach to solving these problems would be to have the device profiles contain only color measurements from characterization targets produced on or scanned into the device. However, such an approach does not adequately account for the difficulty of producing a high quality [device>PCS] transform. To produce such a transform, one must build a model using the color measurements of the targets and the device code values used to produce the targets. The optimum form of such a model depends on the physics of the device being modeled, and there is not a single mathematical form suitable for all types of devices. Furthermore, if the analytical device model is to be converted into a multi-dimensional interpolation table, one must exercise care in the spacing of the lattice of points in the table so that linear interpolation in the table accurately predicts the analytical model. A much better approach is to have the device profiles contain [device>PCS] interpolation tables (as is, indeed, already commonly done in existing color management systems).
What is needed is a system that will allow a [device>device] transform to be created from a [source device>PCS] transform and a [destination device>PCS] transform.